1. The Field of the Invention
The present invention generally relates to message transfer between computing systems using an HTTP request-response type communication. More specifically, the present invention provides for transferring an HTTP response between endpoints as a plurality of different portions in order to conserve valuable system resources associated with validating and authorizing a corresponding HTTP request and to provide two-way communication to a requester in environments where that may not be possible otherwise.
2. Background and Related Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (herein after referred to as “computing system”) to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., packtizing, routing, flow control, etc.). The Open System Interconnect (OSI) model is an example of a networking framework for implementing such a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into several distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. For example, when data is transmitted from a computing system it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received at a computing device from a network, it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer. The application layer, the uppermost layer, is responsible for supporting applications and end-user processes. Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer is the Transmission Control Protocol (TCP).
In a distributed system (e.g., a Web Services environment), services and request for services are frequently transported using (HTTP). HyperText Transfer Protocol operates between the application layer and other lower layers of the OSI model to facilitate the transfer of content in a distributed system environment. Like most network protocols, HTTP uses the client-server model. More particularly, a client computer system (herein after referred as a “client” or “requesting” endpoint) opens a connection and sends a request message over a request flow to a server (herein after referred to as a “server” or “service” endpoint). The server then returns a response message usually containing the resource that was request (e.g., a file, a dynamically-generated query result, or other similar chunk of data) over a reply flow of the HTTP communication. After delivering the response, the server closes the connection; making HTTP a stateless protocol, i.e., not maintaining any connection information between transactions.
Because HTTP is a stateless protocol, HTTP authentication does not support the concept of a session—where a user would login and/or logout. Accordingly, each request to access content that is transported via HTTP (i.e., an HTTP request) must include appropriate HTTP authentication information. As such, there is a tremendous amount of overhead associated with processing the authentication information and validating the client for each request received at a service endpoint.
For example, typically HTTP protocol provides for authentication information to be supplied with each HTTP request via a special header, which is typically in the format of an authentication-type and credentials. The way the client obtains and transmits these credentials is as follows. The first time a client tries to access a website or other such service that requires authentication, the service will typically refuse to provide the requested content or information and will return to the client an HTTP error message (e.g., an unauthorized message) as well as some form of challenge. When the client receives this message it will need to appropriately respond to the challenge using the proper credentials in order to access the service resources. For example, the client upon receiving the challenge may present a user with a popup dialog box that requests a username and/or password. Alternatively, or in conjunction, the challenge may require some other type of credential like a token, e.g., an X.509, Kerberos or other similar token(s). Further, other types of challenges may also be applicable.
Regardless of the type of challenge, after the user (or the client as the case may be) provides the proper credentials (e.g., by typing in a correct password), the client may transmit the original HTTP request to the server; but it may add the authorization header that now includes the credentials as an argument of the header label. If the service accepts the included credentials and returns valid content, the client typically caches these credentials and retransmits them with each new request to the same service or derivative service associated with the same content.
During large file transfers or requests that take relatively large time to process (e.g., a loan process) several requests are made in order to transfer the entire file or process the overall request. This is due in large part to the nature of HTTP, wherein clients are considered un-addressable in that no data can be sent to them without sending it across a reply flow corresponding to the request. Accordingly for large files and overall requests that take time to process, the client must continually send requests that include the authentication information; and the service must continually process such authentication credentials and return the appropriate portions of the overall request as they become available.
This continual authentication and validation process for each request consumes valuable system resources that could be utilized elsewhere (e.g., in the processing the overall response). Similarly, the processing of continued requests associated with the rigidity of firewalls also consumes valuable system resources. As such, there exists a need to be able to keep the reply flow of an HTTP communication open in order to send portions of an overall response to a client as they become available. In other words, there exists a need to be able to receive/send multiple portions of an overall response without having to receive/send several requests for such portions.